Subject: Re: RTP Header Compression for Slow Speed Links

From: David Boardman <[email-masked]>
Date: Mon, 03 Jun 1996 10:01:22 -0700

I think that you are sending this to the wrong email. I am David Boardman
([email-masked]), but I don't understand what this email is about!

Regards...  David BoardmanAt 03:57 PM 5/3/96 -0400, you wrote:
>I am posting the following preliminary (and incomplete) Internet
>Draft, so that we might get some comments and discussion going on
>this list.  Scott and I submitted this just before the last IETF
>in Los Angeles.  We plan to resubmit this with the details of the
>compression technique we have in mind to the avt working group
>mailing list, prior to the next IETF in June in Montreal.
>
>We are also in contact with the pppext working group, which will also
>need to be involved in our approach to this problem.  Our intention
>is to permit RTP to be used efficiently over dial-up modem lines
>as the industry standard for encapsulating realtime voice over the
>Internet, including in Internet Telephony applications.
>
>Please feel free to comment on this list, as it will assist us in
>bringing forward a proposal which developers of Internet Telephony
>software will want to support.  We will post the version with the
>technical details of our proposal as soon as possible.  If you have
>suggestions regarding which technical alternatives you would support,
>now is the time to say so.
>
>We are looking at both VJ Compression and CCP as alternatives.  We expect
>that the compression employed will be limited to the low speed link, in
>order to facilitate multicast.  (By low speed, this could mean anything
>from 14.4kbps up to 128kbps.)  We expect that compression will not be
>end-to-end across the Internet.  This saves each end system from being
>required to keep compression state associated with all other end systems
>in the same multicast group, while retaining the compression on the link
>where it is most valuable: the low speed dial up link.
>
> *************************************************************************
>
> Internet Draft (Preliminary)                           Scott Petrack
>                                                                  IBM
>                                                        Ed Ellesson
>                                                                  IBM
>
>                                                        February 1996
>
>
>                 Framework for C/RTP: Compressed RTP Using
>                 Adaptive Differential Header Compression
>
>         Abstract:
>
>         RTP (Realtime Transport Protocol) has been adopted as a
>         Proposed Standard and is being widely implemented for
>         the synchronized transmission of time-stamped data over
>         IP networks, and has been shown to be effective at LAN
>         speeds, T1 speeds, and Basic Rate ISDN speeds (128 kbps).
>         However, a large number of users access the Internet at
>         speeds of 14.4 and 28.8 kbps.  In order for such users
>         to realize the maximum benefit of realtime audio and video
>         applications, it is reasonable to apply whatever means
>         possible to reduce header overhead.  A framework for
>         header compression of RTP and for associated control
>         protocols is herein proposed for use in these low
>         bandwidth realtime scenarios.
>
>
> Introduction:
>
> RTP (Realtime Transport Protocol) has been adopted as a Proposed
> Standard, and is being widely implemented, for the synchronized
> transmission of time-stamped data over IP networks, and has been shown to
> be effective at LAN speeds, T1 speeds, and Basic Rate ISDN speeds (128
> kbps).  However, a large number of users access the Internet at speeds of
> 14.4 kbps and 28.8 kbps.  In order for such users to realize the maximum
> benefit of realtime applications, it is reasonable to apply whatever
> means possible to reduce header overhead.  By reducing header overhead,
> the relative amount of bandwidth available for transmission of realtime
> audio or video packets can be dramatically increased, while maintaining
> acceptable packetization delay.  At these low speeds, a few kbps in
> additional realtime packet throughput can make a dramatic difference in
> user perception of quality in the received audio or video.
>
> This draft introduces the concepts which we have utilized to reduce
> header overhead in realtime applications.  In order to negotiate or
> pre-arrange header compression options, a session control protocol is
> assumed.  The Session Description Protocol (SDP), defined by the mmusic
> working group, could easily be modified to pre-arrange such compression
> options for loosely controlled conference sessions.  For tightly
> controlled sessions, the Simple Conference Invitation Protocol (SCIP)
> also being defined by the mmusic working group, could be used to
> negotiate or re-negotiate such options.  Alternatively, a modified H.245
> protocol could also be used to negotiate header compression options as
> part of the "capabilities exchange".  The specific modifications to these
> protocols to control header compression options are beyond the scope of
> this draft.
>
> RTP's overhead is approximately 12 bytes per packet, at minimum.  The
> impact of this RTP overhead, when used over low speed access lines, is
> aggravated by the fact that in typical real-time audio applications, the
> packet size is particularly small.  A telephony application using an
> advanced codec might transmit 24 bytes every 30msecs.  Each packet is a
> separate UDP write, which adds an additional 8 bytes.  Thus the total
> overhead for both RTP and UDP is approximately 20 bytes for each 24 byte
> packet.  Over a 14.4 kbps connection, one has no choice but to group
> packets together to reduce the bandwidth requirement, which increases
> delay to an unacceptable degree for realtime interactive voice
> conversations.  Even over a 28.8 kbps link, the overhead of RTP/UDP cuts
> into the bandwidth available to audio and video applications.  This
> translates directly into larger delays in the available service, because
> the payloads must be grouped into larger packets to amortize the RTP/UDP
> overhead.
>
> This draft documents two ideas that we have used to reduce the overhead
> of RTP from 12 bytes to 2 bytes.  This reduction allows us to to
> effectively eliminate the delay caused by RTP overhead on a low speed
> link.  Although applying Van Jacobsen compression to the headers is
> helpful, it is limited by the rapidly varying sequence number and
> timestamp information.  The general compression scheme described here can
> be summarized thus: the timestamp and sequence number fields taken
> together include redundant time signal information.  They can be
> compressed by standard adaptive differential methods.
>
> The extra compression is based on two ideas:
>
>     1. Use the time-related nature of the sequence and time stamp fields.
>        In many cases, timestamps can be replaced by "timeclick numbers"
>        which are one byte long, and these can be combined with the
>        RTP sequence numbers. In general the timestamps and sequence
>        numbers themselves form a simple time signal, and can be
>        compressed without loss by standard adaptive differential
>        methods.
>
>     2. Negotiate compression options before starting the RTP session.
>        In many cases, certain RTP header fields do not change at all
>        during the life of an RTP session.
>
> The two ideas presented here can be used independently.  For example, one
> could send all the header fields in each packet, but still use the
> special time-related nature of some of the fields to compress them.  The
> application that first interested us is transmitting audio and
> audio/video over a PPP link.  In this case the two ideas together give a
> much more efficient use of bandwidth.
>
>
> Time-related compression:
>
> The basic idea here is that one cannot compress time-related data by the
> usual VJ compression, because time related data is constantly changing.
> But the changes in the time related data are often simple to model, and
> an "adaptive differential" scheme can give good lossless compression.
> For example, suppose there are no packet losses and the time stamp of
> each packet increases by exactly one.  In this case, each timestamp is
> different, so VJ compression will not compress, but in fact one can
> dispense entirely with the timestamp field after the first.
>
> In general, there are two separate fields which relate to time:
> the RTP sequence number, and the timestamp.
>
> In our internet telephone example, we have an application which sends one
> UDP packet every 20msecs, except that during silence it sends nothing.
> We always send the packets in order.  Instead of the timestamp and the
> RTP sequence number, we send a single "timeclick number" with each
> packet.  Each number represents 20 msecs, and from the timeclick number
> we know exactly when it was sent (modulo 256*20msecs=5.12secs).  Thus we
> have a precise model for timestamps(i.e. timestamps always increase by
> 20msecs), and this allows us to transmit the information in a single
> byte.
>
>
> Session control and compression:
>
> The second idea is an extension of well known VJ compression.  We have
> found that in multimedia applications over low-speed links, every bit can
> be very precious.  VJ compression is an in-band technique, and uses a few
> bits to signal a header which doesn't change.  One can save several a few
> hundred bits per second by signalling the static parts of the headers out
> of band.  We now discuss this technique.
>
> RTP is designed to run over connectionless, unreliable protocols, but it
> has inherent in it the idea of an RTP session.  We have found that it is
> very natural to set up, control, and tear down an RTP session using a
> separate session control protocol, which, in our implementation, uses a
> reliable form of transmission.  The RTP bytestream itself still runs over
> the unreliable protocol - only the non-real-time control is done via a
> the session control protocol.  One of the important benefits of doing
> this is that we can compress the unreliable RTP bitstream even further.
>
> Example:  Think of a simple audio/video transmission application
> (multicast or unicast).  Before streaming begins, some negotiation or
> advertisement takes place (coder type, block size, bandwidth, etc.).  In
> this way, each side has a common understanding of the coming RTP
> bytestream.  (In our current implementation, the receiver sends a "ready
> to receive" to the sender, and then the sender can start streaming - an
> RTP session has begun.)  The RTP bytestream itself is sent over UDP/IP to
> facilitate real time transmission.  To change a parameter in a session,
> the RTP session stops streaming, and only then some new negotiation takes
> place or the session is torn down and a new one established.
>
> One can use this model to implement every commonly used "phone service",
> including multiparty conferencing.  The simplifying assumption is that an
> RTP parameter can be negotiated only while the RTP stream is not
> streaming.  This negotiation can take place in a comparatively leisurely
> non-real-time manner.
>
> From an end user perspective, pausing the realtime flow to renegotiate
> the control state is not unfamiliar.  Note that this model is very
> similar to that provided by an ordinary analog phone call.  You pick up
> the receiver and do some reliable signalling to set up a connection.
> Once connected, the real-time stream is highly unreliable (noise, echo,
> etc.).  In order to change the control state of the connection, the
> exchange of real-time data must be suspended or stopped (call must be put
> "on hold" or disconnected).  In analog phone systems, the "on hold"
> indication is often signalled via a timed "hook flash", or temporary
> disconnect.  In this paused state the real-time bitstream can be
> renegotiated (e.g., you can dial someone else, etc.).  We do not propose
> this model for all RTP realtime flows, but only those that are associated
> with applications which can dramatically benefit from header compression
> signaling via a separate session control mechanism.
>
> Here is the precise definition of our session mechanism:
>
> 1.  The originator contacts the receiver via some negotiation or
> advertisement protocol and informs or negotiates in non-real-time the
> bytestream characteristics.  (In our implementation, this phase ends with
> the sender sending a messaging expressing readiness to receive.)
>
> 2. At this point the sender can start sending to the receiver using RTP.
>
> 3.  At any point in the stream, the sender can stop sending and then send
> a "pause announcement".  This pause announcement is sent via the session
> control protocol.  (In our current implementation, the receiver
> acknowledges this pause announcement.)  Similarly, the receiver can send
> a "pause request" and then wait for the sender to stop sending.  (In our
> current implementation, the sender complies with such a request by
> stopping to send, and also acknowledges the request by sending a "pause
> announcement" in the control protocol.)
>
> 4.  Once the realtime stream is paused, and the correct pause message has
> been received on each side, then the control connection can be used to
> renegotiate the bitstream (return to item 1, above), or to end the
> session.
>
>
> There are two important points about using the above scheme:
>
> - The RTP bytestream itself is sent by UDP/IP, a stateless protocol.
> All the state information is negotiated in the session control protocol.
> This is possible because there is a very simple synchronization between
> the two channels, done in non-real time.  The statelessness of the RTP
> stream makes it very simple to fulfill the realtime requirements.
>
> - The fact that all negotiation is done BEFORE the RTP stream begins,
> allows the two sides to agree not to send RTP header information that is
> going to remain static throughout the session.  Without this prior
> negotiation, some bits would have to be used to flag these RTP header
> fields.  By simply not transmitting these bits at all, one can squeeze
> several hundred extra bits per second out of a low speed serial link.
> This is often very precious when one is transmitting realtime audio or
> video over a 14.4 kbps link.
>
> To summarize, although RTP allows the possibility to perform control of
> the bitstream on the fly, in practice one can often agree in advance not
> to do this, with no real loss in the useability of the available service,
> depending on the application.
>
>
> Multicast Considerations:
>
> The above discussion spoke about point-to-point unicast only for
> simplicity.  It is easy to generalize to multicast environments, if a
> advertisement or agreement protocol is used to synchronize the state of
> the multiple endpoints.  The essential ideas (using a session protocol to
> negotiate the stateless RTP stream, negotiating to omit uneccessary
> fields, and performing an adaptive differential compression on the time
> stamps and sequence numbers) apply equally in the multicast case.
>
>
> Summary:
>
> We have found that much useful real-time conferencing can be done over
> 14.4 and 28.8 kbps links.  But the difference between the 8+12 byte
> overhead of RTP/UDP and 8+2 byte overhead of C/RTP can be the difference
> between acceptable audio/video quality and intolerable audio/video
> quality.  We definitely think that it is worth supporting 14.4kbps links
> for real-time multimedia.
>
> References:
>
> 1. H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A
>    Transport Protocol for Real-Time Applications", RFC1889,
>
> 2. H. Schulzrinne, "RTP Profile for Audio and Video Conferences with
>    Minimal Control", RFC 1890,
>
> 3. M. Handley, V. Jacobson, "SDP: Session Description Protocol",
>    Internet-Draft, Nov. 22, 1995.
>
> 4. H. Schulzrinne, "Simple Conference Invitation Protocol", Internet-
>    Draft, February 22, 1996.
>
>
> Author's Addresses:
>
> Scott Petrack
> IBM Science and Technology Center
> Haifa, Israel
> Email: [email-masked]
>
> Ed Ellesson
> IBM Networking Architecture
> Research Triangle Park, NC, USA
> Email: [email-masked]
>*******************************************************************************
>
>Regards, Ed
>
>[email-masked]
>legacy voice: 919-254-4115
>
>
>
**********************************
David Boardman
Technical Evangelist
NSAPI, Java, JavaScript, VRML
Netscape Communications Corp.
[email-masked]

---

From: Michael Holland <[email-masked]>
Date: Mon, 03 Jun 96 13:46:14 EDT

Huh?  Something is fouled up.  I never posted this.
Oh well, sorry any way.
mph